In today's complex computer-program and networking environments, code sharing, scalability, and integration with other cross-platform frameworks are generally highly desired. Use of a runtime by a hosting application (i.e., hereinafter often referred to as a “host”) generally allows application developers to write managed code with cross-platform compatibility, increased scalability, a common type system, multiple-language support, automatic memory management, and so on. Runtimes include, for example a Common Language Runtime (CLR), a Java Virtual Machine (VM), and/or the like.
Most hosts consist of both managed code and unmanaged code. Managed code is code that executes under the control of a runtime. Conversely, unmanaged code is code that runs outside of the runtime. Common object model (COM) components, ActiveX® interfaces, and WIN32® API functions are examples of unmanaged code. Unmanaged hosting code is used to configure the common language runtime, load it into the process (i.e., an executing program), and transition the program into managed code.
Other than these basic interactions, once a process is running, interaction between the host and the runtime is typically limited to the host directing the runtime to perform some task. In some cases, the host may receive an event or message to signal that a requested runtime task has completed. Such limited host/runtime interaction represents the substantial lack of integration between the host and the runtime during process execution. For these reasons, the host and the runtime can be said to represent substantially separate entities in a process. Such a lack of execution environment integration between a host and a runtime is substantially limiting in that hosting applications have little or no control over many of the services provided by the runtime.
For example, suppose that the host utilizes cooperative or non-preemptive threading, generally requiring the host to at least have knowledge all threads running in the host's execution environment. Suppose also that a runtime relies on the non-cooperative or preemptive threading model of the OS. (Runtimes typically rely on operating system (OS) threading, memory management, synchronization, security, etc., implementations). In this scenario, the host may send a thread into the runtime. At this point, OS preemptive tasking may block the host's non-preemptive thread and/or the host may move the task to a completely different physical thread. To make matters worse, the host thread may exit the runtime into code that does not belong to the host or the runtime, whereupon just about anything could happen to the host thread without of host knowledge. Such non-integrated host/runtime thread management may substantially degrade host runtime performance and scalability, may result in the loss of data coherence, create deadlocks that the host can not detect, and/or otherwise cause unpredictable host and system behavior.
The foregoing example shows that lack of execution environment integration between a host and a runtime may break the host application's expected implementation(s). This is especially the case when the host has tuned threading, memory, synchronization, and/or security implementations over time for improved scalability and high performance. Thus, although the host may desire the benefits of a runtime use (e.g., cross-platform compatibility, reduced coding efforts, etc.), the host's specially tuned implementation may be incompatible with corresponding runtime services. Accordingly, the host may only load a runtime that relies on host-supplied services, or may completely bypass runtime services by directly accessing underlying OS services. Such work-around(s) do not allow application designers to leverage the benefits runtime system services were designed to provide, resulting in less integrated and portable products.
Accordingly, systems and methods to increase execution environment control between a host and a runtime are greatly desired.